Version control systems are often used today in software development projects and the like, in order to control versions of a product such as a source code and a design specification. A typical version control system stores and manages data of a plurality of versions in a database called a repository. The version control system makes it easy to confirm the history of data updates, and enables to restore data to a previous version by canceling recent updates. Examples of version control systems include Git, Subversion, Mercurial, and so on.
The version control system also facilitates management of a project in which a plurality of version streams are worked on in parallel. For example, a process for modifying software so as to efficiently execute an existing function and a process for adding a new function to the software may be performed in parallel. In this case, the version control system separately stores two version streams (for example, 1.x versions and 2.x versions) in the repository. Each version stream is often called a “branch”.
A plurality of branches may be merged afterwards. For instance, there may be a case where a source code in which an existing function is modified and a source code in which a new function is added are merged in order to test the software in the latest state to which the changes that are made to the two branches are reflected. In this case, for example, the version control system specifies a change made to one of the source codes that are to be merged and a change made to the other one of the source codes, with reference to a previous source code at the time when the branches are forked. Then, after confirming that there is no conflict between the changes, the version control system generates, as a merge result, a source code to which the changes that are made to the two branches are reflected.
Some version control systems separately manage bibliographic information (such as the relationship between versions, the date of update, the author of data, and so on) and the substance data. For example, in Git, three types of objects are stored in a repository: a “commit” containing bibliographic information; a “tree” corresponding to a directory that serves as a container for files and other directories; and a “blob” containing the content of a file. Each object is assigned an identifier calculated from information held by the object, so as to be uniquely identified in the repository.
Since the bibliographic information and the substance data are separately managed, it is possible to prevent data of the same content from being redundantly stored in the repository. For instance, it is assumed that a file of a version and a file of another version have the same content. In this case, in Git, the two blobs (files) have the same identifier, so that only one of the blobs is stored in the repository. Thus, the stored blob is referred to by the two versions.
Further, since the bibliographic information and the substance data are separately managed, it is easy to edit the bibliographic information such as the relationship between versions and the like. For example, it is assumed that a function A is changed in a version, and then a function B is changed in the next version. After that, there arises a need to alter the change history so as to reverse the order of the changes that are made to the functions A and B. In Git, the user may rearrange the order of commits, for example. In this case, since both the functions A and B are changed in the latter version, the last commit after the rearrangement refers to the same tree as that referred to by the last commit before the rearrangement. Further, in Git, the user may combine a plurality of commits, for example. In this case, a resulting combined commit refers to the same tree as that referred to by the last commit before the combining.
As a version control technique, there has been proposed a version control method that prevents changes from being incorrectly applied to or failing to be applied to a source program upon releasing the source program. According to this version control method, when a plurality of modifications are performed in parallel, versions and change records of the first completed modification are registered in a version control table. Then, upon releasing the source program with the second completed modification, the change records registered in the version control table are merged and applied to the source program (see, for example, Japanese Laid-open Patent Publication No. 9-97171).
As a way to proceed with a project, while working on a plurality of branches, these branches may be tentatively merged by using a version control system in order to check the product in the latest state. For example, software development may be proceeded with by repeating a modification of a source code in at least one or more of a plurality of branches and a test on the latest source code generated by a merge of the plurality of branches.
In this case, each time the plurality of branches are merged, the version control system may extract changes from the time when the branches are forked. However, as the amount of changes increases, the workload for a merge operation also increases. To avoid this issue, the version control system may store a previous merge result, and generate a new merge result on the basis of the previous merge result and the changes that are made after the previous merge. Upon merging a plurality of branches, it is possible to determine which previous merge result is usable, on the basis of bibliographic information stored in a repository (in the case of Git, on the basis of a commit graph representing a set of commits, for example).
However, as mentioned above, in some version control systems, the user may edit the bibliographic information. If the bibliographic information is edited after a merge is performed, the bibliographic information after the editing is different from the bibliographic information before the editing. Therefore, upon performing a merge again, it is difficult to find a previous merge result. For example, in Git, if a change (including those that alter the relationship between commits, such as rearranging commits, combining commits, and the like) is made to a commit, the identifier of the commit is changed even when the commit refers to the same tree. Accordingly, if a commit is changed, it is difficult to determine which commits are previously merged only on the basis of the commit graph.